Description
When a CLIP object connects to another CLIP object, either manually or automatically, the translator needs to generate code that maps provider elements to consumer elements. This needs to take account of the dimensionality of each object, and the capability to make repeated connections between element pairs (e.g. to collect multiple buffers from a single store element). The precise element to element mapping is described by a logical string that is referred to as a 'connection signature'.
There are three categories of connection. 'Standard' connections are those that use the default set of rules for mapping between multi-dimensional objects and so the 'signature' can be machine generated; most connections are actually standard (see Multi-Dimensional Connections). 'Regular' connections are those that can be described by a 'signature', but one which does not follow the standard rules and must therefore be entered by the user. 'Irregular' connections are those that cannot be described by a signature and so each element pair needs to be individually specified.
Attributes
All connections can have a 'dimension', and a 'signature', and some can also have a 'repeat count' (see Connection Attributes).
Dimension
If the connection is standard, then this attribute describes the dimensionality of the connection array that is owned by each element of the consumer. So if an [N] element store is connected to an [N] element collector then this would be [1] because by default, each consuming collector element would have one connection to its reciprocal providing store element. If on the other hand, the store had [N][M] elements, and the collector had [N] elements then the connection dimensionality would be [M] because the 'N' dimension will cancel between the consumer and the provider and each collector element would map to 'N' store elements. The dimension is also used to generate the access functions for the connections, where each dimension will have a separate argument, as will the repeat count (Eg Trigger_Tst1Rec( Uns N, Uns M, Uns R ))
Signature
If the connection is standard or regular then this logical string defines the connection mapping between consumer and provider elements and will be used by the translator to generate runtime connection code.
Repeat Count
This attribute determines the number of times that each connection element is repeated. Non unity repeat counts are only valid if the consumer is a collector or a multiplexor; or if the connection is 'manual'.
Signature Generation
When objects are first connected by the Blueprint editor, or when reset is selected from the connection properties menu, the connection dimension is generated from the provider and consumer object dimensions. The signature is then generated from the 'dimension', and in both cases the attributes are calculated using the standard rules. At this stage signature generation is 'enabled'.
While signature generation is 'enabled'; changing the providing or consuming object dimensions, will cause new 'dimension' and 'signature' attributes to be automatically recalculated, but signature generation mode will remain 'enabled'. If the dimension or signature attributes are edited directly however, signature generation will be 'disabled' and the translator will use the non-generated signature. This allows 'regular' signatures to over-ride 'standard' signatures. Selecting 'reset' at any time will re-enable automatic signature generation and recalculate the 'standard' dimension and signature attributes.
Connection signatures come in two basic flavors 'basic' and 'advanced'. The 'basic' variety from the simple, auto generated cases. Whilst the 'advanced' allow uses full control over the connections.
Examples
A 2-d object makes a repeated connection to another 2-d object. Each of the [M][N] elements make R (repeat count) connections to each of the [P][Q] elements.
Dimension [P][Q]
Signature P.Q[^1][^0]
Repeat Count R
See also basic and advanced examples